Chip 1996 April

home *** CD-ROM | disk | FTP | other *** search

/ Chip 1996 April / CHIP 1996 aprilis (CD06).zip / CHIP_CD06.ISO / hypertxt.arj / 9411 / XPROG.CD < prev

Wrap

Text File | 1994-11-23 | 22KB | 367 lines

@VAz X Window System felépítése, programozása@N @VAblakozó rendszer, behálózva@N A népszerû számítástechnika világában -- fôleg Magyarországon -- a technológia értékelése egy számszerû teljesítmény-mutató orientált értékrend szerint történik. A legtöbb értékelésnél egy-egy számmal jelzik egy adott szoftver illetve hardver rendszer vagy elem minôségét. Ez természetesen tökéletesen rendben van akkor, ha az összes fontos mutatót számbavesszük és megfelelôen objektív rendszer alapján pontozunk. Emiatt sokszor egyfajta lista-mánia alakul ki: az a jobb termék, amelynek az elemei nagyobb listát eredményeznek a dobozon. Amellett, hogy így a rendszer összehangoltságára kevés hangsúly kerül (a modularitás eszközének birtokában ennek úgyis külön számbaveendô elemmé kellene válnia), megindul a vadászat az újabb listaelemek után: magasabb verziószám, gyorsabb processzor, nagyobb merevlemezigény után. A valós igény kielégítésére pedig sokszor sokkal kisebb kapacitású eszközök is elegendôek lennének. A szoftverek általában a legjobb hardvert feltételezve készülnek, azon nyújtanak elfogadható teljesítményt -- az egyre jobb hardver minôsége pedig elfedi a szoftver sokszor meglévô problémáit. Ezek pedig a verziószámmal arányosan nônek. Az ilyen, egyre rendezetlenebb rendszerek ellentétei azok, amelyeket eleve jól terveztek meg, és fejlesztésük nem egyszerûen újabb sallangok hozzáadásában merül ki, hanem egy alapgondolathoz illeszkedve, a rendszer architektúrájába szervesen beleillô módon történik. Az átgondolatlanságok káoszából kivezetô utat csak a gondos tervezés adhat. Ebben a cikkben az X Window System felépítésének, programozásának alapjairól lesz szó. Ez -- még az alapoknál maradva is -- elég nagy téma, így egy cikk csak nagy vonalakban ad lehetôséget a tárgyalására. Összehasonlítási alapul a Microsoft Windowst vehetjük, hiszen azt majdnem mindenki ismeri. Bár látni fogjuk, hogy a kinézeten kívül nem sok hasonlóság fedezhetô fel a két rendszer között, mégis jó erre a célra az MS-Windows, mivel a különbségek segítségével könnyebben kiemelhetjük az X jellegzetességeit. @VWindows kontra X Window@N Mielôtt az X és az MS-Windows különbségeit részletesebben elemeznénk, vegyük szemügyre, hogy mi is e különbségek valódi oka, és a rendszerek fejlôdésének szempontjából ez az ok milyen lényeges különbségekre vezet. Az X és az MS-Windows különbségének alapvetô oka az, hogy az egyiket egy egyetem, a másikat egy cég tervezte. Egy cég nyilván a közvetlen anyagi haszon miatt dolgozik, az egyetemi fejlesztési programok célja pedig másfajta haszon szerzése: a személyes tényezôktôl eltekintve, az X létrehozásának célja maga az X volt, pontosabban, hogy létrehozzanak egy olyan rendszert, amely a tervezés elôtt lefektetett alapelveknek és a tervezés során felmerülô technikai követelményeknek minél jobban megfelel. Technikailag a Microsoft Windows rendszerének az a célja, hogy az IBM PC kompatibilis gépek mindennapi használatát (szövegszerkesztés stb.) megkönnyítse, és enyhítse valamelyest a DOS használatával járó kényelmetlenségeket. Az X céljai között is szerepel a parancssor-központú kezelési (felhasználói) felület megtanulásával járó bonyodalmak enyhítése, de nem ez az elsôdleges. Az X tervezésénél az alapgondolat a hálózat-központúság volt: a rendszer a feladatokat egymással megosztó programok kommunikációján, az ezt szabályozó protokollon alapul. Sokan szinonímaként használják az ""ablakozó rendszer" és a ""grafikus kezelési felület" kifejezéseket, mivel mindennapi tapasztalatainkban az MS-Windows egybefûzi azokat. Pedig elég csak a szavak jelentését végiggondolni, és észrevehetjük, hogy a két dolog alapjában véve más. Bárki el tud képzelni szöveges módú ablakozó rendszert és ablakok nélküli grafikus kezelési felületet. Az MS-Windows tulajdonképpen e kettônek az ötvözete, míg az X egy ablakozó rendszer. @VTechnikai különbségek@N Ezek után térjünk a technikai különbségekre. Az X nem egy program. Míg a Windows-DOS együttes tulajdonképpen egyfajta programfuttató rendszert alkot, és a Windowst DOS alatt egy programként indítjuk, az X alapját -- az X rendszer magját -- egy hálózati protokoll képezi, az X Window System Protocol. A protokollok általában a kettô (vagy több) fél közötti kommunikációt teszik lehetôvé, mire való hát az X protokoll? Az X protokoll a kliens és a szerver közötti kommunikációra szolgál. A szerver program kezeli a bemeneti és kimeneti eszközöket -- a hardver erôforrásokat --, felügyel a szoftver erôforrásokra (ezekrôl bôvebben késôbb), fenntartja a kapcsolatot a kliens programokkal és teljesíti kéréseiket. Ilyen kérés például az, hogy a szerver rajzoljon valamit valahova, helyezze át az ablakot stb. E feladatokat tehát nem a kliens program végzi el, hanem a szerver. A kliens csak utasít: ez azt jelenti, hogy -- mivel a protokoll minden szerver esetében ugyanaz -- elég a szervert úgy megírni, hogy tudja használni az alatta lévô hardvert, a kliens programnak már nem kell ezzel foglalkoznia. A kliens programok általában olyan programok, amiket Windows alatt ""alkalmazásoknak" nevezünk, de sok feladatot, amit Windows esetében maga a Windows lát el, X alatt kliens programok végeznek. Ezzel elérkeztünk az X egy másik alapelvéhez: a protokoll a problémák megoldásához mechanizmust szolgáltat és nem irányelvet: a lehetô legnagyobb szabadságot adja meg a programtervezônek. Ez abban is megnyilvánul, hogy sok feladatot a rendszer legalsó rétegeiben meg se fogalmaznak, csak általános eszközöket adnak a programozónak. (A pontosság kedvéért: a kliens szigorúan véve nem program, hanem maga az a csatorna, amelyen keresztül a program kapcsolatot teremt a szerverrel. Ez érthetô, ha belegondolunk, hogy egy programnak nem kötelessége futásának teljes ideje alatt fenntartania a kapcsolatot egy szerverrel, ha viszont nincs szerver, hogyan legyen kliens; másrészt pedig ha figyelembe vesszük azt, hogy egy program több kapcsolatot is fenntarthat ugyanazzal a szerverrel, a szervernek pedig nem is kell tudnia, hogy ugyanarról a programról van szó.) @VAz X programozási szintek@N Persze rögtön felmerül a kérdés: hogyan programozzunk X alatt? Elég csúnyán néznének ki azok a programok, amelyeket közvetlenül az X protokollra írnánk, hiszen egy ablakot nem egy függvényhívással hoznánk létre, hanem mindenféle üzenetek küldözgetésével, ráadásul még egyetlen ablak létrehozása is igen hosszadalmas feladat, annyi paramétert kell a szervernek szolgáltatni. Természetesen a szerver oldaláról érkezô üzeneteket is fel kell dolgozni, ami nem egyszerûsíti le a problémát. Tehát ha egy programot közvetlenül az X rendszerprotokoll alá kellene megírni, akkor elég sok, nehezen megoldható, és sok bonyodalmat, kuszaságot -- strukturálhatatlanságot -- okozó problémával kellene megbirkóznunk. A legegyszerûbb megoldás erre az, ha a protokoll minden egyes elemének (kérésnek, üzenetnek) megfeleltetünk egy-egy függvényhívást, és létrehozunk egy könyvtárat, ami tartalmazza ezeket. A hosszú paraméterlisták megmaradnak, de most már függvénnyel tudunk létrehozni például ablakokat. Az X programozásának tulajdonképpen a legalacsonyabb szintjén ennek a megoldásnak egy -- a programozást jelentôsen egyszerûsítô -- alapbeállításokkal kibôvített változata áll. Ez az Xlib nevû szubrutinkönyvtár. Az egyik legfeltûnôbb különbség a Microsoft Windows és az X programozása között az, hogy az MS-Windowst egyetlen szinten lehet csak programozni, a Windows API szintjén. Ez a szint sok tekintetben közel áll az Xlib szinthez (hosszú paraméterlisták stb.), de van sok jóval magasabb szintû szolgáltatása (például editorablakok), amelyek az X-nél csak a legmagasabb szinteken jelennek meg. (Nem szabad persze elfelednünk, hogy a Windows API függvényhívásai tulajdonképpen rendszerhívások, belépési pontok a futó Windows magba, az Xlib függvényhívások pedig egy hálózati protokoll elemeire fordítódnak le.) Mivel az MS-Windows kezelési felület feladatokat is ellát, valamint egy cég támogatja, kezelési felület tervezésére külön hatékony eszközöket nyújt a programozónak -- míg az X programozásának ezen a szintjén bonyolult kezelési felületeket tervezni nehéz, így a Windows API és az Xlib szint hasonlósága nem egyértelmû. Az Xlib tehát alacsony szintû programozást tesz lehetôvé -- ez azt jelenti, hogy a forráskód nagyon hosszú lesz, sok idôt vesz igénybe a létrehozása, viszont az X minden lehetôségét közvetlenül ki lehet vele használni. Valahogy úgy vagyunk itt is, mint ahogy az assembly nyelvekkel: jobb mint a gépi kód (a protokoll), de pár ezer sor után már összetett feladat mindent kézben tartani -- ugyanakkor van néhány dolog, amit csak ilyen alacsony szinten érdemes vagy lehet megoldani. Persze a mai programozóknak nyilvánvaló a megoldás: használjunk objektumorientált programozási technikákat! Bár az objektumorientáltság sok helyen inkább divat mint szükség, nagyon hatékony eszköz, ha megtaláljuk hozzá a megfelelô feladatot. És egy X-szerû rendszer programozását valóban nagyon jól megoldhatjuk objektumorientált alapokon. Bár amikor ezt a rendszert kitalálták, még nem voltak annyira elterjedtek a kifejezetten OOP-t támogató programozási eszközök, az X fejlesztôi mégis ezt az utat választották. Nincsen mindig szükség az objektumorientáltság összes elônyére, megvalósíthatjuk azt egyszerû C-ben is, gondolták, és a gondolatot tett követte: az eredmény az X Toolkit. (A helyzet mára, az X11 6-os verziójának megszületésével megváltozott: a Fresco az X Toolkithez hasonló, de C++-ra épülô programozási felület.) Az X Toolkit magja szintén egy C nyelvû könyvtár, az X Toolkit Intrinsics (Xt). Az X Toolkit tulajdonképpen lehetôséget ad olyan egységek létrehozására, amelyek egyrészt a program struktúrájában, másrészt pedig az adott program kezelési felületén belül léteznek. Ezeket az objektumokat widgetnek (window gadget -- ablak-szerkentyû) hívják. Ilyenek például a nyomógombok, legördülô menük stb. Widgetekbôl és más kezelési felület feladatokat elvégzô kliensekbôl állnak össze aztán a legmagasabb szintû kezelési felület rendszerek. A legfontosabb ezek közül a szabvánnyá elôlépett Motif (az OSF és a DEC által támogatott kezelési felület rendszer.) A Sun és az AT&T által kifejlesztett OpenLookkal is találkozhatunk még. @VKapcsolatrendszer: az X protokoll@N Egy X-es program futása során lényegében a következô kapcsolatrendszer jön létre: a szerver egy kommunikációs csatornán keresztül kapcsolatban van egy másik programmal, mindketten ugyanazt a protokollt használják. E kapcsolat (egy X alatti program futásának) a fôszereplôi tehát a szerver, a kliens program és a protokoll. Most a szerver és a kliens feladatait vizsgáljuk meg valamivel részletesebben. A szerver elôször is képes a hardver erôforrások, azaz a grafikus megjelenítô egység (monitor stb.), a mutatóeszközök (egér, trackball) és a billentyûzet kezelésére. Képes a szoftver erôforrások kezelésére is, ilyenek az ablakok, a pixmapek (hasonlóak a Windows bitmapjeihez), a kurzorok és a fontok. Ezeken kívül még kétfajta szoftver erôforrás létezik, ezek a grafikus kontextusok és a színtáblák. Egy grafikus kontextus egy rajzolás paramétereit tárolja (vonal vastagsága, színe stb.), a színkezelést pedig az X a színtáblák segítségével valósítja meg. Egy színtábla színcellákból áll, a színcellák pedig RGB értékeket tárolnak. Egy-egy pixel tulajdonképpen egy színcellát címez, a valódi szín ott tárolódik. Az, hogy egy színcellán belül hány biten kerül tárolásra az RGB érték, hogy hány biten és milyen módszerrel indexeljük a színtáblát, változó, az adott szerverre jellemzô. Ezenkívül feladata a szervernek a klienssel való kommunikáció: a szerver a kliens kéréseit teljesíti, esetleg válaszol rájuk, valamint bizonyos eseményekrôl értesíti a kliens programot. A protokollnak tehát képesnek kell lennie e háromféle üzenet továbbítására. A kliensek szerverrel való kommunikációjával válik lehetôvé a kliensek közötti kommunikáció megvalósítása. Ez a postaládának nevezett objektumokkal történik. A postaládák tartalmának a szerver nem tulajdonít jelentést, csak beállítja ôket illetve kiolvassa tartalmukat a kliens utasítása szerint. @VA kliens feladatai@N Egy kliens programnak is több dolgot kell elvégeznie: elôször is meg kell teremtenie a kapcsolatot az X szerverrel, inicializálnia kell az alapvetô objektumokat (ablakok, fontok stb.), és le kell kezelnie az X szerver által hozzá közvetített eseményeket. Ezeket a dolgokat Xlib szinten mind külön-külön kell megtenni, míg magasabb szinteken bonyolultabb vezérlési és adatstruktúrák igénybevételével könnyebben végezhetjük el ôket. Gyakorlatilag ez annyit jelent, hogy Xlib szinten programozva minden program végén ott láthatunk egy eseménykezelô ciklust, az Xt viszont lehetôvé teszi (a widgetekhez kapcsolódóan) azt, hogy bizonyos eseményekre a megfelelô válasz típusát elôre megadjuk, így a programok végén csak egy hívást találhatunk az Xt magasszintû eseménykezelô rutinjához. A kliensek egymással is kommunikálnak a szerveren keresztül a postaládák segítségével. A legtöbb kliensnek kommunikálnia kell például az ablakmenedzserrel. Ez egy speciális program, ez kezeli az ablakok átfedését, átméretezését, áthelyezését. Ez a kliens adja meg az ablakok dekorációját is (a keretet, a kereten a gombokat stb.). Tulajdonképpen ez a program határozza meg egy-egy kezelési felület kinézetét. Egy ablak létrehozásakor például megmondjuk az ablakmenedzsernek, hogy az ablak, amit létre akarunk hozni, milyen paraméterekkel rendelkezzen lehetôség szerint (méret, elhelyezkedés stb.) Az ablakmenedzser erre úgy válaszol, hogy megmondja, hogy milyen valós méretekkel rendelkezik az ablak, a kliensnek pedig e szerint kell folytatnia mûködését. A kliens feladata tehát végrehajtása esetén a szerverrel való kapcsolat kezdeményezése, az adatstruktúrák (például widgetek) inicializálása, majd az események lekezelése. A legtöbb elvégzendô részfeladathoz tartozhat felhasználói preferencia. Elképzelhetô, hogy a felhasználó szeretné megadni, hogy ez meg az az ablak milyen színû legyen, a ""Cancel" helyett inkább ""Mégsem" szerepeljen egy nyomógombon stb. Az ilyen típusú feldatok megoldását segítik az erôforrásleíró file-ok. Az Xt a widgetek bizonyos jellemzôit (egy gombra írt szöveg stb.) erôforrásként kezeli, és egy-egy program bármilyen ilyen típusú erôforrását tetszôlegesen meg tudjuk változtatni a programon kívülrôl, egy erôforrásleíró file használatával. Itt tulajdonképpen azt írjuk le, hogy milyen erôforráshoz milyen értéket rendelünk. E file-okat az Xt futásidôben megnézi, és a megfelelô erôforrásokat e szerint állítja be. @VHogyan tovább?@N Az X programozásának elméleti részének ezzel a végére értünk: a többi rész már a gyakorlat, hiszen az elmondott elvek valahogy megvalósításra kerültek, és a gyakorlatban is alkalmazni kell ôket. Bár ez a cikk nem fedi le az X programozásának összes elméleti jellemzôjét, az alapokat megmutatja. Ha valaki ennél mélyebben szeretné megismerni az X programozását, az nehéz feladat elôtt áll, mivel Magyarországon még elég kevés ilyen típusú anyag van. Amit tenni lehet, az az, hogy beszerezzük egy-egy X programozási tanfolyam jegyzetét, elolvassuk az 1013 számú RFC-t (X Window System Protocol, Version 11.), az általunk elérhetô dokumentációkat stb. Az X Consortium példa X rendszere és a hozzá tartozó dokumentáció megtalálható a prep.ai.mit.edu ftp szerveren (ez az X Consortium hivatalos ftp szervere, de ugyanezeket a dolgokat Magyarországon is megtalálhatjuk például a sunserv.sztaki.hu címen). Persze jóval egyszerûbb dolga van annak, aki hozzáfér idegennyelvû szakirodalomhoz, ami -- a magyarhoz képest legalábbis -- elég bôséges. @KÉder Géza@N ┌──────────────────────────────────────────────────────────┐ │ @VAz X Window és a Windows különbségei@N │▒ │ │▒ │ Az X egy ablakozó rendszer, de nem grafikus kezelési │▒ │ felület -- az MS-Windows mindkettô. │▒ │ │▒ │ Az X nem egy operációs rendszer, hanem egy protokoll │▒ │ köré épül, kihasználja az operációs rendszerek │▒ │ alapszolgáltatásait (bizonyos fokú erôforráskezelés, │▒ │ IPC stb.) │▒ │ │▒ │ Az X egy egyetemi fejlesztés végeredménye, az │▒ │ MS-Windowst pedig egy cég fejlesztette. Ezért az │▒ │ MS-Windows egyszerûbb, közvetlenül próbál alkalmazkodni │▒ │ a felhasználók igényeihez; az X bonyolultabb, nem célja │▒ │ az ilyen típusú alkalmazkodás (de megadja rá a │▒ │ lehetôséget). Legfontosabb feladatai: │▒ │ │▒ │ @V*@N Grafikus (raszteres) ablakozó rendszer │▒ │ megvalósítása; │▒ │ │▒ │ @V*@N Hálózati átlátszóság; │▒ │ │▒ │ @V*@N Eszközfüggetlenség. │▒ └──────────────────────────────────────────────────────────┘▒ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒